The electronic storage and transmission of information is being used increasingly for commercial transactions. Commercial information is particularly complex because it may include data input from different sources which must be kept together in order to have a meaningful document or series of documents. Also, some of this data may be highly sensitive information, such as financial data, coupled with other information of lesser or no sensitivity.
Electronic information of this type may be maintained in different ways, for example, in the form of a single electronic file having multiple sections or data fields (a compound file), as multiple separate electronic files or documents, or in a combination of compound electronic files. It may be required that these files be stored in a computer system, or interchanged between two users over the same computer system or over a network of different systems.
Depending on the level of sensitivity, different portions of the electronic information may require different forms of security protection to prevent unauthorized access either to view the information, or to modify or alter the information.
Implementing secure file formats with entire file integrity has long been recognized as a requirement for data storage systems. In such systems, the inter-relationship of all records is generally maintained and encapsulated under a single file hash value, such as is discussed in U.S. Pat. No. 5,475,826 to Fischer, titled "Method for Protecting a Volatile File Using a Single Hash".
U.S. Pat. No. 5,504,892 to Taligent, Inc. is titled "Extensible Object-Oriented File System", and discloses an example of a system in which the hierarchical nature of object-oriented programming has been utilized to provide a framework for an extensible object-oriented file system with a file system entry class which is sub-classed into a volume, directory and file subclass. User authentication and protection domains are used to protect against unauthorized access to file system entities. User authentication is achieved by providing a local authentication service, and protection domains are implemented through a method of one of the file system entities. In order to provide interoperability with foreign file systems, a mechanism is disclosed for packaging a foreign file into a compatible format before transporting it to the system disclosed in the patent. The files are unpackaged into the format of the foreign file system when transported back to it.
U.S. Pat. No. 4,713,753 of Honeywell Inc., titled "Secure Data Processing System Architecture with Format Control", illustrates another data processing system architecture for the secure storage and processing of data using file format control and a protected file system. In this method, the protected systems files remain at all times within a secure processor, and user access to the files is provided as a function of a comparison between the formats associated with the files and the function of each file's attributes or the subsystem performing the requested operations.
European Patent Application No. EP66165 1-A1 discloses unification of a directory service with a file system service, and stores the directory entries and other files in a common logical format. This system allows a common set of tools to operate on both such entities and a common name space to be utilized. Security measures are taken to prevent unauthorized access to directory service entries.
Two IBM Technical Disclosure Bulletin publications, "Data Base Security/Authorization Mechanisms" (Vol. 28, No. 3, August 1985) and "Change-Notification Service for Shared Files" (Vol. 36, No. 8, August 1993), describe database security and authorization mechanisms including file maintenance utilities with file formats.
In electronic commerce applications, some financial data in the transaction may require encryption, other information may require data integrity (read-only access), and the entire transaction, or portions of it, may require a digital signature. The transaction may also contain addressing information in a plain text form to permit it to be interpreted by communications software. The entire transaction file cannot simply be encrypted to protect the most sensitive information, since this would transform the communication addressing information into a form that is unreadable to the communication software.
Encryption of only a portion of a file has previously only been implemented in a few types of files. For example, encryption algorithms are available which permit the encryption of certain cells in a spreadsheet. However, this technology is not available for a wide class of file formats or for files intended for electronic transmission. Also, the encryption of portions of files cannot be combined with other security requirements over the same or other portions of the files.
A simple electronic consumer purchase is an example of a transaction involving a single compound document requiring multiple security protections. Each transaction file may include multiple data fields, and each of the data fields may have a different security requirement than others in the same transaction. For example, data such as the credit card number and expiry date may require encryption, addressing information may require data integrity, and the entire transaction may require a digital signature.
Similarly, in a realty transaction, the buyer and seller usually negotiate on a standard form. Most of the information printed on the form does not require any form of security protection. However, the price will be confidential and may require encryption, particularly if the offer is to be transmitted over a non-secure network. Conditions attached to the offer may also require encryption, and because conditions may be deleted or expanded in a counter-offer, the encrypted information may not be of uniform size from one transmission to the next. In addition, any changes made by a party during the negotiation will have to be signed (initialed) by the party making the change.
Other types of commercial applications may include multiple files or documents resulting, for example, from having the electronic documentation for the transaction prepared by more than one person or emanating from more than one source. A typical commercial transaction with a government body could include the ultimate purchase order, as well as the background documents. Other examples of commercial transactions are the quotation, the invitation to quote, the tender and the invitation to tender, the invoice, and the acknowledgment.
Because the several documents relate to a single transaction, all of the files should be packaged together for transmission or storage. However, each file in the package may have its own security requirements, independent of the type of security required for other files used in the transaction, and therefore, there is a requirement to be able to wrap multiple files as a single entity having multiple security requirements for exchange or storage for these applications.
There are several utility programs currently available for packing multiple files into a single file for transmission or storage (eg., PKZIP on PC and tar on UNIX). There are also mechanisms that provide for data exchange between multiple file records, such as found in U.S. Pat. No. 5,021,995 of Wang Laboratories, Inc., titled "Data Exchange Apparatus and Methods", which discloses data exchange between file records with the production of a generic form for representing data that is used to mark fields in the source file logical record, and U.S. Pat. No. 5,522,066 of Industrial Technology Research Institute, titled "Interface for Accessing Multiple Records Stored in Different File System Formats", which discloses an interface for accessing multiple records stored in different file system formats. However, none of these provide a means for maintaining different security features associated with individual files or records once a number of files or records have been accessed or packed together.